Method and apparatus for triggering machine type communications applications

ABSTRACT

A method and apparatus for triggering at least one machine type communications (MTC) application using at least one wireless transmit/receive unit (WTRU) is disclosed. The method includes receiving a triggering message including a device trigger (DT) and a maximum delayed response time value from a core network entity (CN), storing the DT in the WTRU, initiating a timer in the WTRU set to the maximum delayed response time value, and on a condition that the timer expires, the WTRU transitioning to a radio resource control (RRC) connected mode and dispatching the DT to the MTC application.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/570,682, filed Dec. 14, 2011 and U.S. Provisional Application No.61/590,941, filed Jan. 26, 2012, the contents of which are herebyincorporated by reference herein.

BACKGROUND

With the progress of the wireless technologies and mobile networkdeployments, wireless services for machine type communication (MTC)through the mobile network has become an important agenda under thethird generation partnership project (3GPP). Mobile networks arecurrently designed for human-to-human communications, and are lessoptimal for machine-to-machine (M2M) or machine-to-human applications.MTC provides data communication involving one or more entities that donot necessarily need human interaction.

Wireless transmit/receive units (WTRUs) are generally programmed toautonomously set up a connection to report an event through the mobilenetwork. However, in some applications and services it may be requiredthat the network trigger the WTRUs. For example, during a storm, a waterauthority may desire to monitor dike and dam sensors in a specific area.It is expected that millions of these types of WTRUs may be deployed,and may be polled or triggered to initialize a message or a shortmessage service (SMS) by a network signal.

Since a large number of WTRUs may be triggered at the same time in arelatively localized area for specific applications, causing too manynetwork resources to be consumed, enhancement of a point-to-pointdelivery mechanism for WTRU triggering may be desirable.

SUMMARY

A method and apparatus for triggering at least one machine typecommunications (MTC) application using at least one wirelesstransmit/receive unit (WTRU) is disclosed. The method includes receivinga triggering message including a device trigger (DT) and a maximumdelayed response time value from a core network entity (CN), storing theDT in the WTRU, initiating a timer in the WTRU set to the maximumdelayed response time value, and on a condition that the timer expires,the WTRU transitioning to a radio resource control (RRC) connected modeand dispatching the DT to the MTC application.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1A shows an example communications system in which one or moredisclosed embodiments may be implemented;

FIG. 1B shows an example wireless transmit/receive unit (WTRU) that maybe used within the communications system shown in FIG. 1A;

FIG. 1C shows an example radio access network and an example corenetwork that may be used within the communications system shown in FIG.1A;

FIG. 2 shows an example of 3GPP architecture for Machine-TypeCommunication (MTC);

FIG. 3 shows an example network architecture for delivering a triggervia cell broadcast services (CBS);

FIG. 4 shows an example of downlink non-access stratum (NAS) evolvedpacket system (EPS) mobility management (EMM) MTC device trigger requestmessage used to carry content to an MTC application;

FIG. 5 shows an example of a downlink NAS EMM MTC device trigger requestmessage used to carry short message service (SMS) content;

FIG. 6 shows an example of a paging method;

FIG. 7 shows an example subframe allocation used by MTC Devicetrigger/reach paging;

FIG. 8 shows an example paging message indicating that a paging triggeris for MTC device triggering;

FIG. 9 shows an example RRC paging/MTC device trigger message having thenew message format;

FIG. 10 shows an example of a delay response procedure;

FIG. 11 shows that an MTC device/WTRU may delay a response messagetransmitted by an MTC application;

FIG. 12 shows an example of the message format of dual purpose MTCdevice service or attach+trigger response message;

FIG. 13 shows an example of extended-service request message content;

FIG. 14 shows an example bit map that defines a cause value; and

FIG. 15 shows the primary EMM states in an MTC device/WTRU.

DETAILED DESCRIPTION

FIG. 1A shows an example communications system 100 in which one or moredisclosed embodiments may be implemented. The communications system 100may be a multiple access system that provides content, such as voice,data, video, messaging, broadcast, and the like, to multiple wirelessusers. The communications system 100 may enable multiple wireless usersto access such content through the sharing of system resources,including wireless bandwidth. For example, the communications systems100 may employ one or more channel access methods, such as code divisionmultiple access (CDMA), time division multiple access (TDMA), frequencydivision multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrierFDMA (SC-FDMA), and the like.

As shown in FIG. 1A, the communications system 100 may include WTRUs 102a, 102 b, 102 c, 102 d, a radio access network (RAN) 104, a core network106, a public switched telephone network (PSTN) 108, the Internet 110,and other networks 112, though it will be appreciated that the disclosedembodiments contemplate any number of WTRUs, base stations, networks,and/or network elements. Each of the WTRUs 102 a, 102 b, 102 c, 102 dmay be any type of device configured to operate and/or communicate in awireless environment. By way of example, the WTRUs 102 a, 102 b, 102 c,102 d may be configured to transmit and/or receive wireless signals andmay include user equipment (UE), a mobile station, a fixed or mobilesubscriber unit, a pager, a cellular telephone, a personal digitalassistant (PDA), a smartphone, a laptop, a netbook, a personal computer,a wireless sensor, consumer electronics, and the like.

The communications systems 100 may also include a base station 114 a anda base station 114 b. Each of the base stations 114 a, 114 b may be anytype of device configured to wirelessly interface with at least one ofthe WTRUs 102 a, 102 b, 102 c, 102 d to facilitate access to one or morecommunication networks, such as the core network 106, the Internet 110,and/or the other networks 112. By way of example, the base stations 114a, 114 b may be a base transceiver station (BTS), a Node-B, an evolvedNode-B (eNB), a Home Node-B (HNB), a Home eNB (HeNB), a site controller,an access point (AP), a wireless router, and the like. While the basestations 114 a, 114 b are each depicted as a single element, it will beappreciated that the base stations 114 a, 114 b may include any numberof interconnected base stations and/or network elements.

The base station 114 a may be part of the RAN 104, which may alsoinclude other base stations and/or network elements (not shown), such asa base station controller (BSC), a radio network controller (RNC), relaynodes, and the like. The base station 114 a and/or the base station 114b may be configured to transmit and/or receive wireless signals within aparticular geographic region, which may be referred to as a cell (notshown). The cell may further be divided into cell sectors. For example,the cell associated with the base station 114 a may be divided intothree sectors. Thus, in one embodiment, the base station 114 a mayinclude three transceivers, i.e., one for each sector of the cell. Inanother embodiment, the base station 114 a may employ multiple-inputmultiple-output (MIMO) technology and, therefore, may utilize multipletransceivers for each sector of the cell.

The base stations 114 a, 114 b may communicate with one or more of theWTRUs 102 a, 102 b, 102 c, 102 d over an air interface 116, which may beany suitable wireless communication link, (e.g., radio frequency (RF),microwave, infrared (IR), ultraviolet (UV), visible light, and thelike). The air interface 116 may be established using any suitable radioaccess technology (RAT).

More specifically, as noted above, the communications system 100 may bea multiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. Forexample, the base station 114 a in the RAN 104 and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as universal mobiletelecommunications system (UMTS) terrestrial radio access (UTRA), whichmay establish the air interface 116 using wideband CDMA (WCDMA). WCDMAmay include communication protocols such as high-speed packet access(HSPA) and/or evolved HSPA (HSPA+). HSPA may include high-speed downlinkpacket access (HSDPA) and/or high-speed uplink packet access (HSUPA).

In another embodiment, the base station 114 a and the WTRUs 102 a, 102b, 102 c may implement a radio technology such as evolved UTRA (E-UTRA),which may establish the air interface 116 using long term evolution(LTE) and/or LTE-Advanced (LTE-A).

In other embodiments, the base station 114 a and the WTRUs 102 a, 102 b,102 c may implement radio technologies such as IEEE 802.16 (i.e.,worldwide interoperability for microwave access (WiMAX)), CDMA2000,CDMA2000 1X, CDMA2000 evolution-data optimized (EV-DO), Interim Standard2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856(IS-856), global system for mobile communications (GSM), enhanced datarates for GSM evolution (EDGE), GSM/EDGE RAN (GERAN), and the like.

The base station 114 b in FIG. 1A may be a wireless router, HNB, HeNB,or AP, for example, and may utilize any suitable RAT for facilitatingwireless connectivity in a localized area, such as a place of business,a home, a vehicle, a campus, and the like. In one embodiment, the basestation 114 b and the WTRUs 102 c, 102 d may implement a radiotechnology such as IEEE 802.11 to establish a wireless local areanetwork (WLAN). In another embodiment, the base station 114 b and theWTRUs 102 c, 102 d may implement a radio technology such as IEEE 802.15to establish a wireless personal area network (WPAN). In yet anotherembodiment, the base station 114 b and the WTRUs 102 c, 102 d mayutilize a cellular-based RAT, (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A,and the like), to establish a picocell or femtocell. As shown in FIG.1A, the base station 114 b may have a direct connection to the Internet110. Thus, the base station 114 b may not be required to access theInternet 110 via the core network 106.

The RAN 104 may be in communication with the core network 106, which maybe any type of network configured to provide voice, data, applications,and/or voice over Internet protocol (VoIP) services to one or more ofthe WTRUs 102 a, 102 b, 102 c, 102 d. For example, the core network 106may provide call control, billing services, mobile location-basedservices, pre-paid calling, Internet connectivity, video distribution,and the like, and/or perform high-level security functions, such as userauthentication. Although not shown in FIG. 1A, it will be appreciatedthat the RAN 104 and/or the core network 106 may be in direct orindirect communication with other RANs that employ the same RAT as theRAN 104 or a different RAT. For example, in addition to being connectedto the RAN 104, which may be utilizing an E-UTRA radio technology, thecore network 106 may also be in communication with another RAN (notshown) employing a GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102 a,102 b, 102 c, 102 d to access the PSTN 108, the Internet 110, and/orother networks 112. The PSTN 108 may include circuit-switched telephonenetworks that provide plain old telephone service (POTS). The Internet110 may include a global system of interconnected computer networks anddevices that use common communication protocols, such as thetransmission control protocol (TCP), user datagram protocol (UDP) andthe Internet protocol (IP) in the TCP/IP suite. The networks 112 mayinclude wired or wireless communications networks owned and/or operatedby other service providers. For example, the networks 112 may includeanother core network connected to one or more RANs, which may employ thesame RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102 a, 102 b, 102 c, 102 d in thecommunications system 100 may include multi-mode capabilities, i.e., theWTRUs 102 a, 102 b, 102 c, 102 d may include multiple transceivers forcommunicating with different wireless networks over different wirelesslinks. For example, the WTRU 102 c shown in FIG. 1A may be configured tocommunicate with the base station 114 a, which may employ acellular-based radio technology, and with the base station 114 b, whichmay employ an IEEE 802 radio technology.

FIG. 1B shows an example WTRU 102 that may be used within thecommunications system 100 shown in FIG. 1A. As shown in FIG. 1B, theWTRU 102 may include a processor 118, a transceiver 120, atransmit/receive element, (e.g., an antenna), 122, a speaker/microphone124, a keypad 126, a display/touchpad 128, a non-removable memory 130, aremovable memory 132, a power source 134, a global positioning system(GPS) chipset 136, and peripherals 138. It will be appreciated that theWTRU 102 may include any sub-combination of the foregoing elements whileremaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), amicroprocessor, one or more microprocessors in association with a DSPcore, a controller, a microcontroller, an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA)circuit, an integrated circuit (IC), a state machine, and the like. Theprocessor 118 may perform signal coding, data processing, power control,input/output processing, and/or any other functionality that enables theWTRU 102 to operate in a wireless environment. The processor 118 may becoupled to the transceiver 120, which may be coupled to thetransmit/receive element 122. While FIG. 1B depicts the processor 118and the transceiver 120 as separate components, the processor 118 andthe transceiver 120 may be integrated together in an electronic packageor chip.

The transmit/receive element 122 may be configured to transmit signalsto, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, thetransmit/receive element 122 may be an antenna configured to transmitand/or receive RF signals. In another embodiment, the transmit/receiveelement 122 may be an emitter/detector configured to transmit and/orreceive IR, UV, or visible light signals, for example. In yet anotherembodiment, the transmit/receive element 122 may be configured totransmit and receive both RF and light signals. The transmit/receiveelement 122 may be configured to transmit and/or receive any combinationof wireless signals.

In addition, although the transmit/receive element 122 is depicted inFIG. 1B as a single element, the WTRU 102 may include any number oftransmit/receive elements 122. More specifically, the WTRU 102 mayemploy MIMO technology. Thus, in one embodiment, the WTRU 102 mayinclude two or more transmit/receive elements 122, (e.g., multipleantennas), for transmitting and receiving wireless signals over the airinterface 116.

The transceiver 120 may be configured to modulate the signals that areto be transmitted by the transmit/receive element 122 and to demodulatethe signals that are received by the transmit/receive element 122. Asnoted above, the WTRU 102 may have multi-mode capabilities. Thus, thetransceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, forexample.

The processor 118 of the WTRU 102 may be coupled to, and may receiveuser input data from, the speaker/microphone 124, the keypad 126, and/orthe display/touchpad 128 (e.g., a liquid crystal display (LCD) displayunit or organic light-emitting diode (OLED) display unit). The processor118 may also output user data to the speaker/microphone 124, the keypad126, and/or the display/touchpad 128. In addition, the processor 118 mayaccess information from, and store data in, any type of suitable memory,such as the non-removable memory 130 and/or the removable memory 132.The non-removable memory 130 may include random-access memory (RAM),read-only memory (ROM), a hard disk, or any other type of memory storagedevice. The removable memory 132 may include a subscriber identitymodule (SIM) card, a memory stick, a secure digital (SD) memory card,and the like. In other embodiments, the processor 118 may accessinformation from, and store data in, memory that is not physicallylocated on the WTRU 102, such as on a server or a home computer (notshown).

The processor 118 may receive power from the power source 134, and maybe configured to distribute and/or control the power to the othercomponents in the WTRU 102. The power source 134 may be any suitabledevice for powering the WTRU 102. For example, the power source 134 mayinclude one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li—ion),and the like), solar cells, fuel cells, and the like.

The processor 118 may also be coupled to the GPS chipset 136, which maybe configured to provide location information (e.g., longitude andlatitude) regarding the current location of the WTRU 102. In additionto, or in lieu of, the information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from abase station, (e.g., base stations 114 a, 114 b), and/or determine itslocation based on the timing of the signals being received from two ormore nearby base stations. The WTRU 102 may acquire location informationby way of any suitable location-determination method while remainingconsistent with an embodiment.

The processor 118 may further be coupled to other peripherals 138, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 138 may include anaccelerometer, an e-compass, a satellite transceiver, a digital camera(for photographs or video), a universal serial bus (USB) port, avibration device, a television transceiver, a hands free headset, aBluetooth® module, a frequency modulated (FM) radio unit, a digitalmusic player, a media player, a video game player module, an Internetbrowser, and the like.

FIG. 1C shows an example RAN 104 and an example core network 106 thatmay be used within the communications system 100 shown in FIG. 1A. Asnoted above, the RAN 104 may employ an E-UTRA radio technology tocommunicate with the WTRUs 102 a, 102 b, 102 c over the air interface116. The RAN 104 may also be in communication with the core network 106.

The RAN 104 may include eNBs 140 a, 140 b, 140 c, though it will beappreciated that the RAN 104 may include any number of eNBs whileremaining consistent with an embodiment. The eNBs 140 a, 140 b, 140 cmay each include one or more transceivers for communicating with theWTRUs 102 a, 102 b, 102 c over the air interface 116. In one embodiment,the eNBs 140 a, 140 b, 140 c may implement MIMO technology. Thus, theeNB 140 a, for example, may use multiple antennas to transmit wirelesssignals to, and receive wireless signals from, the WTRU 102 a.

Each of the eNBs 140 a, 140 b, 140 c may be associated with a particularcell (not shown) and may be configured to handle radio resourcemanagement decisions, handover decisions, scheduling of users in theuplink and/or downlink, and the like. As shown in FIG. 1C, the eNBs 140a, 140 b, 140 c may communicate with one another over an X2 interface.

The core network 106 shown in FIG. 1C may include a mobility managemententity (MME) 142, a serving gateway 144, and a packet data network (PDN)gateway 146. While each of the foregoing elements are depicted as partof the core network 106, it will be appreciated that any one of theseelements may be owned and/or operated by an entity other than the corenetwork operator.

The MME 142 may be connected to each of the eNBs 140 a, 140 b, 140 c inthe RAN 104 via an S1 interface and may serve as a control node. Forexample, the MME 142 may be responsible for authenticating users of theWTRUs 102 a, 102 b, 102 c, bearer activation/deactivation, selecting aparticular serving gateway during an initial attach of the WTRUs 102 a,102 b, 102 c, and the like. The MME 142 may also provide a control planefunction for switching between the RAN 104 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

The serving gateway 144 may be connected to each of the eNBs 140 a, 140b, 140 c in the RAN 104 via the S1 interface. The serving gateway 144may generally route and forward user data packets to/from the WTRUs 102a, 102 b, 102 c. The serving gateway 144 may also perform otherfunctions, such as anchoring user planes during inter-eNB handovers,triggering paging when downlink data is available for the WTRUs 102 a,102 b, 102 c, managing and storing contexts of the WTRUs 102 a, 102 b,102 c, and the like.

The serving gateway 144 may also be connected to the PDN gateway 146,which may provide the WTRUs 102 a, 102 b, 102 c with access topacket-switched networks, such as the Internet 110, to facilitatecommunications between the WTRUs 102 a, 102 b, 102 c and IP-enableddevices.

The core network 106 may facilitate communications with other networks.For example, the core network 106 may provide the WTRUs 102 a, 102 b,102 c with access to circuit-switched networks, such as the PSTN 108, tofacilitate communications between the WTRUs 102 a, 102 b, 102 c andtraditional land-line communications devices. For example, the corenetwork 106 may include, or may communicate with, an IP gateway, (e.g.,an IP multimedia subsystem (IMS) server), that serves as an interfacebetween the core network 106 and the PSTN 108. In addition, the corenetwork 106 may provide the WTRUs 102 a, 102 b, 102 c with access to thenetworks 112, which may include other wired or wireless networks thatare owned and/or operated by other service providers.

Hereinafter, the terms “WTRU,” “MTC device,” and “device” may be usedinterchangeably.

FIG. 2 in an example of 3GPP architecture for Machine-Type Communication(MTC). A Services Capability Server (SCS) 205 is an entity whichconnects to the 3GPP network to communicate with WTRUs 225 used for MTCand the MTC-inter-working function (MTC-IWF) 201 in the HPLMN 240 or ashort message service (SMS) service center (SMS-SC) 210 for devicetriggering. The SCS 205 may offer capabilities for use by one ormultiple MTC Applications 240. The WTRU 225 may host one or multiple MTCApplications 240. The corresponding MTC Applications 225 in the externalnetwork may be hosted on one or multiple Application Servers (ASs) 260ultimately connected to the SCS 205.

Tsms 255 may be the interface that encompasses all the variousproprietary SMS-SC 210 to a short message entity (SME) interface 265standards and may be outside the scope of 3GPP specifications. The Tsms255 may be used to transmit a trigger to a WTRU 225 encapsulated in a MTSMS as an over-the-top application by any network entity acting as anSME 265. Tsp 270 is a 3GPP standardized interface to facilitatevalue-added services motivated by MTC 201, for example control panedevice triggering, and provided by the SCS 205.

An Application Programming Interface (API) may be used as an abstract toillustrate an example of an end-to-end view for MTC and to simplifymapping to MTC specifications of other standardization organizations. Inan indirect model, MTC capabilities and the MTC Application in theexternal network may be collocated on the same SCS 205.

For a roaming scenario, the MTC-IWF 204 may have the connection with ahome subscriber server (HSS) 215 and SMS-SC 210 within the home networkonly and with serving SGSN/MME/MSC 220(a)/(b)/(c) in a visited network.

MTC device triggering may start from the MTC application 250. An MTCapplication 250 may configure the SCS 205 for MTC device triggering. TheSCS 205 may transmit a device triggering request to the MTC-IWF 201 withexternal MTC device identities (not necessarily 3GPP identifiers) viathe Tsp interface 270.

The MTC-IWF 201 plays a role in bridging the SCS 205 and the public landmobile network (PLMN) for handling the MTC device triggering and otherfunctionalities. An MTC-IWF 201 may co-exist with the SMS-SC 210 with aninterface T4 230 or may connect to the SMS-SC 210 externally with a T4230.

The MTC-IWF 201 interrogates the home location register (HLR)/HSS 215,when needed, to map external identifiers to international mobilesubscriber identity (IMSI) or to some other MTC device internal ID(known to 3GPP network) and gather the device/WTRU 225 reachability andconfiguration information. The MTC-IWF 201 then selects the triggerdelivery mechanism, for example, T4-SMS 240, T5-direct 235, orT5-direct-SMS 235, and performs protocol translation if necessary, androutes the request towards a relevant core network (CN) entity. Forexample, protocol translation may be necessary to reformat the triggeredrequest to match the selected trigger delivery method.

The MTC device trigger requests generated by the MTC-IWF 201 may go tothe CN controlling nodes over the T5 interface 235. For example, the CNcontrolling nodes may be a mobility management entity (MME) 220(b),serving general packet radio service (GPRS) support node (SGSN) 220(c),or mobile switching center (MSC) 220(a). The CN controlling node maymake a decision on how the MTC device triggering is delivered to the MTCdevices/WTRUs 225. An MTC device trigger may then be transmitted to theMTC devices/WTRUs 225 to invoke the MTC devices/WTRUs 225 performingcertain actions and/or respond back.

The MTC-IWF 201 may transmit an SMS request in terms of an MTC devicetrigger over the T4 interface 230 to the SMS-SC 210, which may thengenerate and/or package the MTC device trigger in SMS form and dispatchthe SMS to an MSC 220(a). It may then go to the WTRU 225 directly or viathe SGSN/MME 220(c)/(b).

The MTC device may already be attached to the network and have a dataconnection with the network, or it may be attached to the network buthave no connection established. In this case, it is called “online,”which means that the MTC devices are registered with the network.

The MTC device may be unattached to the network or “offline,” whichmeans that the device is currently in an “unregistered” state with thenetwork. The network may still have some knowledge about the MTC device.The MTC-IWF may need to keep the SGSN/MME addresses of an MTC device,per its IMSI or its device ID.

Additionally, the 3GPP network may support control signaling between thenetwork entity SCS/SME and the 3GPP system via the Tsms reference pointfor submission of the device trigger requests as part of user data of amobile terminated SMS (MT-SMS). The Tsms reference point is provided byan SMS-SC. The SMS-SC may reside at the edge of the operators' network.The SCS may request the SMS-SC to deliver a device trigger over the Tsp.

In LTE, the network may reach the idle mode WTRUs through pagingoperations such that the network transmits paging messages at specifictime occasions to the WTRUs having an incoming call. The WTRUs may bemonitoring the paging periodically in occasions assigned to them basedon their WTRU IDs. The WTRUs may be identified by the WTRU ID in thepaging message.

Alternatively, the network may reach idle mode WTRUs by broadcasting asystem information broadcast periodically according to a schedule. WTRUslooking for system information may check and receive the systeminformation when it is broadcast according to the scheduling.

Alternatively, the network may reach the idle mode WTRUs throughmultimedia broadcast multicast services (MBMS) mechanisms such that thenetwork multicasts MBMS information and data over the multimediabroadcast over single frequency network (MBSFN) subframes (where noregular unicast is ongoing) and the WTRUs supporting MBSFN subframereception may monitor the control information and receive the MBMS dataon the MBSFN subframes according to the MBMS scheduling.

For MTC devices that are location fixed or location known, the networkmay employ some broadcast/multicast mechanisms for device triggeringwhether they are currently registered or not. The PLMN maymulticast/broadcast a trigger message in a relevant cell or group ofcells for efficiency to meet MTC communication scaling requirements. TheMTC devices may be programmed to monitor a preset cell broadcastchannel, even when they are not attached to the network, and haveassigned a unique paging identity (UPID). The SCS may transmit the MTCdevice trigger in cell broadcast messages to its MTC devices this way ifthe location information is available in the SCS.

For cell broadcast service (CBS) configuration, a mobile networkoperator may provide an interface to the cell broadcast center (CBC) tothird parties. The SCS may transmit a trigger containing, for instance,geographic information and trigger information to the MTC-IWF over Tsp.The MTC-IWF may then act as a cell broadcast entity (CBE) to deliver themessage to the CBC. The CBC may then distribute the cell broadcastmessage to the relevant MME. The CBS in LTE may be equated to theemergency warning message distribution.

FIG. 3 shows an example network architecture for delivering a triggervia CBS. The network architecture in FIG. 3 includes the CBE 301, theMTC-IWF 305, the CBC 310, the MME 315, the RNCs 320, the eNBs 325, a 3Gnetwork 330, and an LTE network 335.

In 3GPP 330, for the Earthquake and Tsunami Warning Service (ETWS) andArea Mail systems, the distribution area may be specified in cell units.However, in LTE 335, the distribution area may be specified in threedifferent granularities: cell, tracking area, or emergency area (EA).

When the CBC 310 receives a request for emergency informationdistribution from the CBE 301, it may create a text to be transmitted tothe terminals and specifies the distribution area from the informationin the request. The CBC 310 may then transmit a write replace warningrequest message to the MME 315. When the MME 315 receives this message,it transmits the information to the eNBs 325 as specified in thedistribution area.

When the eNBs 325 begin transmission of the emergency information, apaging message in which the ETWS indication is set is transmitted to themobile terminal, for example, the WTRU. If a paging message containingan ETWS indication is received, the terminal begins receiving the systeminformation broadcast that contains the emergency information. The eNBs325 may use the message identifier to determine how the message isbroadcasted, the distribution area (cell list), primary notificationidentifier, and secondary notification information, if available. Uponcompletion of a broadcast, the eNBs 325 return the result to the MME315.

Core network congestion avoidance and backoff (BO) timers may be used inconjunction with MTC devices. A BO timer may be used to avoid congestionin a network due to access by numerous devices. Note that the BO timersalso apply to WTRUs that are not MTC devices. BO timers may apply toWTRUs that are configured as low priority devices, for example, MTCdevices, and to WTRUs that are not configured for low priority devices.Devices that are configured as low priority may set the radio resourcecontrol (RRC) establishment cause to “delay tolerant” when they attemptto obtain an RRC connection.

There may be a general mobility management BO timer per core network(CN) domain. For example, T3346 may be used for a packet switched (PS)domain and T3246 may be used for a circuit switched (CS) domain. This BOtimer may also be referred to as a session management BO timer.

There may be a BO timer per access point name (APN). This timer may beused for session management to setup, modify, or release packet datanetwork (PDN) connections. The WTRU may run at least one BO timer. Eachtimer may map to only one APN. This BO timer may also be referred to asa session management BO timer.

The WTRU may run both a mobility management and session managementtimer. If a mobility management timer is running in the WTRU, then theWTRU may not initiate a request, except if the WTRU is establishing aPDN connection for emergency calls or already has such a PDN connectionestablished, or the WTRU is accessing the system with a specific accessclass 11-15. In both of these cases, the establishment cause used toobtain an RRC connection may not be set to “delay tolerant”. The eNBmay, upon detection of congestion, reject a connection after identifyinga device as low priority, for example the RRC establishment cause=“delaytolerant”. The eNB may also provide a WTRU with a BO timer at the RRClayer. This BO timer may be known as an extended wait timer (EWT). Whenthis happens, the RRC layer in the WTRU may provide the timer to thenon-access stratum (NAS) which may run the mobility management timerwith a value set to that of the indicated EWT.

A WTRU that is requesting a connection and the establishment cause doesnot indicate “delay tolerant”, (even if the WTRU is configured as a lowpriority device, e.g., the WTRU sets an establishment cause to“emergency”, despite being a “delay tolerant” device), may receive anEWT. If this occurs, the RRC may provide it to the NAS, which may ignorethe EWT as this only applies to accesses with establishment cause set to“delay tolerant”.

Given the T5 interface in FIG. 2 and the mechanism with the T5 directMTC device triggering to the WTRU using an NAS message though the CNcontrolling node, embodiments for the new NAS message based solutionsare disclosed including the T5 interface protocol. The new NAS messagetriggering mechanism may need new procedures over new parameters thatwould fulfill the task of device triggering within the 3GPP network.

Since a large number of MTC devices may be triggered around the sametime in a relatively localized area for certain specific MTCapplications, the point-to-point delivery mechanism for MTC devicetriggering may not be optimum since it may consume too many networkresources at the same time. For downlink reaching methods, multicastmechanisms and enhanced paging mechanisms may be used.

A BO timer may be applied to devices that are low priority as well asdevices that are not low priority. If the BO timer is running in theWTRU, for example, the mobility BO timer, the WTRU may request aconnection and access the system if the WTRU needs to setup an emergencycall, (or already has setup one), or if the WTRU is accessing the systemwith access class 11-15. The WTRU may be allowed to receive emergencycalls, but the network operator may not want the WTRU to transmitadditional requests for other PDN connections that are not related toemergency calls, for example, not related to IMS emergency calls.However, since the WTRU may only be running a mobility management timer,but not a session management timer, the WTRU may not see any restrictionthat prevents it from transmitting session management requests.

One possible method to combat this may be to configure the WTRU suchthat, if the WTRU is already running a BO timer, then the WTRU may notinitiate other session management requests unrelated to the emergencycall if it has a PDN connection for emergency calls and the WTRU wasbacked off. Also, the network may provide the WTRU with sessionmanagement BO timers to prevent this from occurring. However, theprimary problem may be that when the WTRUs ignore the BO timers andtransition to a connected mode, (for example, for emergency calls orbecause of accessing the system with access class 11-15), the networkmay not be able to differentiate between the WTRUs that are requestingemergency calls but do not belong to access class 11-15, and WTRUsrequesting emergency calls but belong to access class 11-15. If thisinformation is missing at the network, the network may blocknon-emergency requests from all WTRUs that have an emergency PDNconnection, even though the WTRUs that belong to access class 11-15 havethe “right” to access the system for non-emergency purposes.

Embodiments for delivering the MTC device triggers from the MTC-IWF tothe WTRU are described hereafter.

A T5 interface may connect an MTC interworking function (MTC-IWF) to arelevant CN node. Specifically, the T5 a interface may connect theMTC-IWF to an SGSN, the T5 b interface may connect to an MME, and the T5c interface may connect to an MSC. Both T5 a and T5 b interfaces may beIP network interfaces. GTPv2 is the top level protocol and GTPv2 runsover the UDP transport. The T5 interface may be used to carry MTCrelated SMS messages as well as other MTC related formatted messagessuch as NAS messages, for MTC device triggering or other purposes. Oneor more of the following attributes may be used to build a GTP tunnel (adistinct TEID) over the T5 interface: MTC message type (for example, SMSvs. other plain format messages) or a delivery mechanism; deliveryscheduling priority and/or delivery schedules and/or traffic types (forexample, establishing connection over c-plane only or u-plane connectionneeded or other types of triggering results); an individual RAN node ora group of RAN nodes (for example, eNBs or NodeBs or HeNBs/HNBs); localnetworks (for example, selected IP traffic offload (SIPTO)/local IPaccess (LIPA) nodes, such as L-GWs); mobile location areas (for example,tracking areas or routing areas); MTC device type or deviceservice/application category; and MTC device (WTRU) current connectionstatus (for example, idle vs. connected). The T5 interface may not onlytransport an MTC device trigger request and response messages betweenthe MTC-IWF and the relevant CN nodes, the T5 interface may also carrythe message for MTC device (upon roaming) location update information orthe WTRU registration status information, including its DRX/sleep cycleconfiguration and lengths, from the CN nodes to the MTC-IWF.

The following procedures, messaging, transactions may be used in anycombination. The CN node may transmit an acknowledgement that a requestis being processed. The CN node may transmit an acknowledgement that arequest is being processed, with a result of the processing. Forexample, the result of the processing may be failure or success and areason code. The reason code may indicate the failure of thereachability using a specific method, for example, failure to reach viaSMS, or failure to reach via user plane (UP). This may be used by therecipient (e.g., MTC-IWF) to try another reachability method. The CNnode may transmit a failure due to unavailability of resources,alternatively with a backoff (BO) period during which the recipient(e.g., MTC-IWF) may not retry. The BO time may be for a specific deviceor for all devices, or a group of devices. In general, one node thatimplements the T5 interface may at any time inform another node aboutcongestion start or end for one, a group, or all devices. The BOindication may be associated with an interval during which no requestmay be made. An exception to this rule may be requests for urgent oremergency communication or communication to a device that is highpriority or that is a member of a specific class, and the like. Thus, anode (e.g., MTC-IWF) may indicate in all the T5 messages whether therequest is for a “regular” or “prioritized” device or application withina device.

When the MTC-IWF has determined to invoke an MTC device trigger via theT5 interface, a T5 MTC device trigger message may be dispatched to thetarget. The T5 MTC device trigger message may be transmitted from theMTC-IWF to the CN controlling node, such as MME, SGSN, or MSC. Thecontent and parameters of the message and the related semantics aredescribed below. An MTC device trigger message from the MTC-IWF to theCN controlling node may contain one or more device triggers to one ormore MTC devices or to one or more MTC device groups.

One or more of the following parameters may be transmitted in the T5message to the CN controlling node for a device to be triggered: triggerrequest validity time, triggered device internal identities, MTC devicelocations, device reaching mechanisms, trigger device response expected,MTC device application profile, MTC device response time, MTC responsetype, trigger delivery urgency, and MTC device application ID.

The trigger request validity time may be the time that is passed to theCN controlling node to determine if the trigger is still valid. Thetriggered device internal identities, within a PLMN, may include theWTRU device ID, assigned MTC device ID, device paging/multicast ID,and/or device group ID in paging or multicast.

The MTC device locations may be, for example, tracking/routing area IDs,cells, such as cell-IDs physical cell identities/primary scramblingcodes (PCIs/PSCs), a local health network (LHN) ID, home NodeB (HNB) ID,and closed subscriber group (CSG) ID. The device reaching mechanism maybe, for example, point-to-point, paging, broadcast, and multicast. Thetrigger device response expected may be, for example, user plane(U-plane), control plane (C-plane) only, and simple-ACK.

The MTC device application profile may be, for example, access pointname (APN) and operating system (OS) profile. The MTC device responsetime may be the time at which the device may respond, the time beforewhich the device may manage or respond, the time after which the devicemay respond, or a time interval, (i.e., specified by a start and endtime) during which a device may respond. The MTC response type may bewhether an individual response is required for an independent device ora device that is part of a group of devices or a group-based response isdesired.

The trigger delivery urgency indicator may be a trigger that needs to bedelivered regardless of whether the network is overloaded or not.

The MTC device application ID may be used to trigger at least oneapplication or multiple applications within the device. This may be abitmap that identifies the applications. A value of 1 may indicate thatthe trigger applies to the application related to the bit position and avalue of 0 may indicate that the application (corresponding to theposition of the bit in question) is not being triggered. The relation ofbit position to the type of application may be configured and known toboth the device and the network, or may be negotiated upon registrationof the device. In addition, there may be one application ID for whichall of the above items are provided, for example, regarding responsetime, response type. Alternatively, all of the previous items may beapplicable to all the applications that are being triggered. Moreover,some of the above items may apply to all or specific applications. Forexample, the response time or type may be for all applications, or theremay be such information per application.

The above parameters may be used in any combination and are notrestricted to MTC devices. Alternatively, these parameters may bepre-configured in the devices or preconfigured in the CN nodes oraccording to operator policies. The CN nodes may provide the requiredresponse characteristics, for example, as per the above parameters.

For an MTC-IWF generating MTC trigger requests to the CBC, to enablegroup MTC device triggering, another granularity of triggering area maybe introduced to specify an MTC triggering area for MTC devicesbelonging to a certain PLMN, operator, and the like. A PLMN specificmessage identifier may be used so that WTRUs not interested in themessages may discard them.

When the MTC-IWF receives MTC device trigger requests from the SCS, theMTC-IWF may determine which device trigger delivery mechanism to use toreach the concerned MTC device or MTC devices. The MTC device triggerdelivery mechanisms may include (but not limited to) one or more of thefollowing. An SMS delivery mechanism over the T4 interface towards theSMS-SC, subsequently using SMS delivery path. A direct messagetransmitted over the T5 interface towards the CN controlling node. AnSMS properly formed at the MTC-IWF and encapsulated in a T5 ProtocolData Unit to the MME/SGSN. A control or command transmitted towards thePDN gateway (P-GW)/gateway GPRS support node (GGSN) or to servinggateway (S-GW) for the MTC device trigger to go over the usualuser-plane path to the MTC devices.

In the case that a particular WTRU (MTC device) has so registered suchthat more than one delivery mechanism may be used, for example, a WTRUhas registered with CS and PS for SMS and PS for NAS message triggering,the delivery mechanism may be chosen by the MTC-IWF according to one ormore of the following: information acquired from the HSS subscriptionrecord, information accumulated in the MTC-IWF, for example, during WTRUregistration operation, mobility management operations, network loadmanagement (SON) from the CN nodes, or information supplied by theMTC-server or the MTC operation, administration, and maintenance (OAM).

The MTC-IWF may try several methods according to a specific order whichmay be based on an ordered list of methods as received from the HSS, oras preconfigured in the MTC-IWF or as per recommended method that may bereceived from any CN node. The above methods may be used in anycombination.

The MTC user, for example, a power meter company, may specify a deliverymethod for all the devices it tries to reach, or the user of the MTCdevice/WTRU in the subscription data may give consent for a preferredmethod.

The MTC device may be in one of the following operating states:connected currently active, connected in long discontinuous reception(DRX) state/mode, idle state but remain registered, or offline orderegistered. For connection currently active, the MTC may use apoint-to-point delivery method such as SMS or direct NAS message. Forconnected in long discontinuous reception (DRX) state/mode, the MTC mayuse a T5 delivery method to invoke multicast triggering. For idle statebut remain registered, the MTC may use a T5 delivery method to invokemulticast triggering. For offline or de-registered, the MTC may use a T5delivery method to invoke multicast triggering.

The MTC-IWF may receive relevant CN load conditions and/or relevant RANload conditions, and may choose a lighter-loaded path (hence thedelivery mechanism) to dispatch the triggering indication. MTC devicelocation in the PLMN network may be considered where a certain deliverymechanism is available or preferred. If a U-plane path for MTC-deviceresponse is expected, the point-to-point SMS or NAS message trigger maybe used. If a C-plane response is needed, any method may be used. If asimple ACK is needed, a NAS message+a multicast method may be used.

The MTC-IWF may deliver the MTC triggers over the T5 interface if thetarget CN is not overloaded. However the MTC device triggers, markedwith a “trigger delivery urgency indicator,” may be delivered to thecongested CN. The MTC device triggers with the “trigger delivery urgencyindicator” may come from those particular SCSs specifically authorizedand/or authenticated to input such urgent device triggers.

The MTC-IWF may collect the responses from the T5 interface on variousT5 trigger requests. If a negative acknowledgment comes back from theMME, or no response is received during a specific time interval, one ofmore of the following may be performed by the MTC-IWF. The MTC-IWF mayinitiate another delivery if the original request is still valid, forexample, remaining time in validity period. Alternatively, if the CN isoverloaded and the validity time is not over, a suspend report andsubsequent actions of the MTC-IWF may be based on a failure value fromthe MME/SGSN/MSC. Alternatively, the MTC-IWF may transmit a failurereport to the SCS, or to a default node. The default node may bepreconfigured in the MTC-IWF or may be specific to every device. Forexample, the HSS may provide the MTC-IWF that the SMS-SC is the defaultnode, or last resort destination, for a particular device or group ofdevices in which all or a subset of other reachability methods fail.

The MME/SGSN may decide whether the MTC device trigger may be deliveredusing point-to-point NAS message, SMS, via RAN level paging, or CBS. TheMME/SGSN may also decide whether the MTC device trigger maybe deliveredusing a multicast method based on the WTRU state, WTRU location, WTRUcapability, such as, registered information, RAN load situation, and thetrigger request validity time duration. One or more of the followingconsiderations maybe used by the MME/SGSN.

The MME/SGSN may decide that the device trigger may be deliveredpoint-to-point via an NAS MTC device trigger message or an SMS message,if the MTC device/WTRU is in a connected state with an active C-planeconnection, if the trigger validity time is longer than the expected MTCdevice/WTRU's next non-MTC related uplink activity, if the device is ina RAN, cell, or area, for example, a tracking area (TA), routing area(RA), location area (LA), that is not heavily loaded, or if the triggerrequest comes from the MTC-IWF with the preference of point-to-pointdelivery. For example, related uplink activity may be the next trackingarea update (TAU).

The MME/SGSN may decide to use one-to-many signaling, for example,paging, CBS, or multicast, if one or more of the following is relevant:if the MTC device/WTRU is in a connected state but under long DRX mode(in the MTC this may mean one half minute to several days or more) orthe MTC device/WTRU does not have an RRC Connection, if the WTRUcapability indicates it may receive one-to-many signals, for example,paging, CBS or multicast; if the trigger validity time remainingindicates a trigger action needs to be taken soon; if the triggerrequest comes from the MTC-IWF with the preference of a point-to-manydelivery method; if there is a large number of triggers from theMTC-IWF; or if the eNB, where the device to be triggered resides,supports one or more of the point-to-many delivery for MTC devicetriggers.

When the MME decides to use point-to-many delivery mechanism, for MTCdevice trigger requests from the MTC-IWF, the MME may buffer/accumulatethe similar requests together for a while for the same eNB or for asimilar trigger time. For example, the MME may buffer/accumulate acertain portion of the request validity time.

The MME/SGSN may hold back the delivery of triggers to the RAN that haveindicated overload. However those triggers that are marked with an“urgency indicator” may be delivered to the RAN regardless ofoverloading/congestion or not.

Alternatively the delivery mechanism decision may be made by an eNB orjointly by the MME and the eNB. For point-to-many delivery of the MTCdevice triggers, the eNB may decide which mechanism to use, how the MTCdevice responds, and how to schedule the trigger delivery.

The MME and/or the eNB may collect the responses or the acknowledgmentsfrom the MTC devices/WTRUs and determine whether a re-attempt or afailure report or failure action may be taken.

For a network node CBC in the MTC device trigger system, when the CBCtransmits a trigger related message to the MME, a new message identifiermay be introduced from the CBC to the MME to initiate the MTC devicetrigger start/replace. The new message may map to an existing or newprimary notification and include additional information such asdistribution area, MTC group identifier, a list of MTC devices that arebeing triggered, repetition period, and number of broadcasts requested.

In order to avoid that this capability does not interfere with theoriginal purpose of the CBS, for example, warning system for naturaldisasters and other events, the CBC may assign priorities to theentities assigned to it, and the message identifiers it receives. TheCBC may ensure that all public warning messages are broadcast before anyMTC triggering messages are broadcast.

In order to address the scalability of using the broadcast resources fortriggering a large number of devices, the CBC may spread the MTCtriggering notifications to restrict the number of devices triggered permessage, or transmitted a new distribution period to the eNB.

A home NodeB (HNB) and home evolved NodeB (H(e)NB) gateway (H(e)NB-GW)may be deployed as a proxy to handle the MTC devices. Under this modelMTC devices may be locally attached to the H(e)NB without requiringperiodic network registrations. Such devices may be present at theH(e)NB subsystem level.

In a deployment where MTC devices, low priority devices or any otherdevice holding similar characteristics, need to be contacted to eitherpush or pull data, the concept of HeNB GW may be used to enable at leastthe following capability. The MTC device may register to the HeNB GWprior or during regular network registration and the HeNB GW may be usedas a proxy to allow for addressing the device using a group-ID based onthe HeNB GW-ID or for periodic HeNB GW registration with a periodicityless or equal to the regular periodic network registration.

If an MTC device roams into a different PLMN, or if the MTC deviceincurs any tracking area change or serving cell change that may involvea serving CN node change, the target CN node may need to update theMTC-IWF on the location changing of the particular MTC device or WTRU.The update information may include the WTRU-Id including the MTC-ID orthe MTC-Group-Id, the IMSI or other forms of MTC device internal ID, orthe new location information such as cell-id, RAN-node-Id, or Area-Id.The device MTC information may include one or more of the schedulinginformation, for example, the DRX cycle length, the current C-planeand/or U-plane connection information, and additional RAN mechanisminformation, for example, using MBMS or using CBS for triggering.

The target CN node may obtain the information from the source CN nodeduring the roaming handling procedure, or the target CN node may obtainthese information from the RAN node or from the WTRU directly. If an MTCdevice moves to a different tracking area or changes to a differentserving cell within the same CN node, the target RAN node may need toupdate the CN node with one or more of the pieces of informationdescribed above.

An NAS MTC device trigger, for example, an MTC device trigger request,message may be constructed at the mobility management (evolved packetsystem (EPS) mobility management (EMM) or global multimedia mobility(GMM)) level at the MME. The NAS MTC device trigger message may bedelivered to an MTC device or WTRU when it is in evolved packet system(EPS) mobility management (EMM)-connected mode(EMM-registered-normal-service). Alternatively an existing downlink NASMM level message may be modified to contain one or more of the followingparameters with similar semantics defined below to perform the MTCdevice trigger.

The NAS MTC device trigger message may contain one or more of thefollowing parameters: an MTC device ID or MTC device group ID, an MTCdevice trigger authorization code, a security parameter for subsequentdevice-network interaction, a trigger request type, a response type andduration, a response ID, a response resource type, aresponding-area-scope, an MTC device message container, and a type ofMTC application or application ID.

The MTC device ID or the MTC device group ID may be that with which theWTRU performs some authorization check to see if it is the intendedrecipient given the group-paging, CBC and the multicast. The MTC devicetrigger authorization code helps the WTRU to verify the trigger source(SCS) feature for MTC feature control, whether the MTC device is allowedto be triggered this way. The security parameter for subsequentdevice-network interaction may be for example, a KSI, anencryption-algorithm or a security nonce. The presence or absence ofthis parameter may determine the WTRU response security level.

The trigger request type may be, for example, the purpose of thetriggering. For example a trigger that is simply for monitoring to seeif the device is still alive or a trigger that may command the device toperform some task, such as to open a gate, or a trigger to ask thedevice to transmit certain data and then download new software and thenreset. The trigger request type may dictate how the WTRU is to respondto the trigger.

The response type and duration may indicated whether the WTRU responsemay be immediate or may be delay tolerant within the duration or theWTRU may use higher priority approach if at the end of the responseduration. The response ID may be assigned by the MME to identify theWTRU response. The response resource type may be, for example, U-planeEPS-bearer, associated APN, LGW, or C-plane, or a simple response suchas ACK. The responding-area-scope, for example, if the device isroaming, may indicate in which cell, which area, or which PLMN the WTRUis allowed to transmit the response.

The MTC device message container may include MTC application specificcontents to the possible MTC layer or to the MTC application. The typeof MTC application or application ID may be used to indicate which oneMTC application needs to transmit the response if there are multiple MTCapplications running on the device.

FIG. 4 shows an example of a downlink non-access stratum (NAS) evolvedpacket system (EPS) mobility management (EMM) MTC device trigger requestmessage used to carry content to an MTC application. The “MTC specificmessage container” information element (IE) may allow the MTC specificapplication information to be encapsulated therein. This may facilitatethe specific information passing either to an MTC layer, if there aremultiple MTC applications on a device, or to the MTC application.

FIG. 4 includes information element indicator (IEI) 405, an informationelement 410, a type/reference of the information element 415, presenceof the information element 420, format of the information element 425,and length of the information element 430. The information elementscontained in the EMM message may be protocol discriminator 410(a),security header type 410(b), MTC device trigger request 410(c), MTCdevice ID or group ID 410(d), authorization or security code 410(e), MTCdevice trigger request type 410(f), trigger response resource type410(g), response ID 410(h), response area scope 410(i), and MTC specificmessage container 410(j). When the MTC device/WTRU receives the MTCdevice trigger request message, the MTC device/WTRU may respond with anMTC device trigger response message to the MME. The IEI for the MTCspecific message container IE 410(j) is XX 405(j).

The T5-Direct-SMS interface is between the MTC-IWF and the MME, whichmay be used to carry MTC device trigger SMS for PS-only WTRUs. When thenetwork is equipped with this capability, the network may indicate thiscapability/configuration/setup to the WTRUs in system informationdirectly or embedded in the NMO part of the system information elements.The network may also indicate the capability/confirmation/setup to theWTRUs in NAS response messages to the first WTRU NAS request messages,for example, attach accept or TAU accept. A PS-only WTRU with thisT5-direct-SMS capability may register to this type of service withspecial “PS-only-SMS” attach type in single and combined attachactivities.

If the WTRU has more than one MTC trigger reception capability, the WTRUmay choose one capability for the session, or the WTRU may indicate allfor subsequent MTC-related communications and let the network pick onemechanism for subsequent operations. For example, the MTC receptioncapabilities may be SMS, NAS message, or direct-MTC-SMS.

When the MTC-IWF needs to transmit a trigger message over T5 SMS to theWTRU, the MTC-IWF may first verify, either through an HSS, an SCS orsome other entity in the network or directly, whether or not it has a T5connection to the MME. When the T5 association with the MME is createdthen the MTC-IWF may continue with the procedure. The MTC-IWF may buildand encapsulate the SMS message into the value part of the NAS messagecontainer information element of a T5-DOWNLINK-DATA message or a similarmessage and transmit this message to the MME. This NAS message containeror the T5-downlink-data message may contain a new element indicatingthat this SMS is over device trigger purpose.

When the MME receives a T5-downlink-data message, the MME may copy thecontents of the NAS message container information element to the valuepart of the NAS message container information element of a Downlink NASTransport message and transmit the downlink NAS transport message to theWTRU. It may also transmit a special indication informing the WTRU thatthe SMS message is for paging the MTC device. This procedure may beapplied for the uplink case when the device transmits an SMS response tothe trigger request message.

If the WTRU is in an idle mode, the MME may transmit a page message fordevice trigger. This paging message may contain an indication informingthe WTRU that it is for device trigger. Upon receiving this paging, theWTRU may start the service request procedure, and the MME may thenforward the trigger SMS as part of a service request procedure.

In addition to carrying the MTC specific message in the above describedMTC device trigger request, the message may be used to carry an SMS toan MTC device at the point of an MME. Message format wise, this may beaccomplished through explicit coding through the IEI field, such that aspecial IEI=XY indicates the SMS container.

FIG. 5 shows an example of a downlink NAS EMM MTC device trigger requestmessage used to carry SMS content. This message may use a carryingcontainer type to indicate which kind of payload, (MTC specific or anSMS), is included. FIG. 5 includes IEI 505, an information element 510,a type/reference of the information element 515, presence of theinformation element 520, format of the information element 525, andlength of the information element 530. The information elementscontained in the EMM message may be protocol discriminator 510(a),security header type 510(b), MTC device trigger request 510(c), triggercontent type 510(d), MTC device ID or group ID 510(e), authorization orsecurity code 410(f), and MTC SMS container 510(j). The IEI for the MTCSMS container IE 510(j) is XY 505(j).

If the WTRU is in an EMM-idle mode or in an EMM-deregistered state, theMME may page the WTRU. If the WTRU learns from the paging that an MTCdevice triggering is in effect, other than a pure WTRU paging, the MTCdevice may respond with a different first MM message, other than theService Request with “paging response”, as the MTC device triggerresponse and may establish a different signaling path avoidingunnecessary U-plane bearer establishment.

The current RRC paging message may be modified to inform WTRUs that thisis a paging for an MTC device trigger.

FIG. 6 shows an example of an RRC paging method. As shown in FIG. 6, theWTRU-ID 601 may be set to be an MTC-ID-info 605 or an MTC-group-ID-infoinside the paging record IE paging WTRU-ID. A new field called“MTC-ID-info” 615 may be added to indicate that the concerned pagingrecord is for an MTC device trigger or some other MTC related downlinkreaching activity. The MTC-ID-info 605 or the MTC-group-ID-info IE mayexpand to the field MTC-identity-info 610, which may contain one or moreof the following information specifically for the MTC activities: thevalue of the IMSI or international mobile equipment identity (IMEI) ofthe MTC device; the value of an assigned MTC identity or the MTC GroupID of the device; the category or the purpose or the intended actioncommand of the MTC paging action, for example, for an MTC devicetrigger, for an MTC small data Tx, for an MTC device monitoring check,for a device to take an action (i.e., open/close a gate), or for adevice maintenance action; and the paging response type indicatorindicating how the WTRU responds to this paging. For example, the WTRUmay respond by establishing a regular EPS connection or establishing asignaling connection or act for a simple response to the paging.

In order to not impact the legacy WTRUs, or non MTC WTRUs, with theexisting paging procedures by the MTC device triggering/reachingspecifics (i.e. the more frequent paging occasion intent), one or moreof the following may be employed by the network and the MTCdevices/WTRUs.

In a first example, the paging message for MTC devices/WTRUs may betransmitted on a different time occasion than the regular paging. Thepaging message may be transmitted on a different LTE frame than theregular WTRU paging frames as the following scheduling form:

(SFN+j) mod T=(T div N)*(WTRU_ID mod N),   Equation (1)

where j is an offset frame number separating an MTC paging frame from aregular paging frame and j=[1, 2, . . . , (T div N)−1]. The frame offsetnumber j may be predetermined or network configured. The WTRU ID may becalculated by IMSI or by MTC identity.

In a second example, the same or different LTE paging frame may be used,but the MTC triggering/reaching signal/message may be on a differentsubframe, for example, subframes other than #0, #4, #5 and #9. In oneexample, subframe #3 and #8 may be allocated to the MTC devicetrigger/reach, such that when MTC devices using MTC-ID to compute forthe subframe number, the new number of subframes formula is modified to:

Ns=Max (1, nB/2T).   Equation (2)

FIG. 7 shows an example subframe allocation used by MTC Devicetrigger/reach paging. FIG. 7 includes the number of subframes (Ns) 705,paging offset 710 (PO) when i_s=0, and PO 715 when i_s=1.

A new indication may be added to the paging message to indicate thepaging trigger is for an MTC device triggering. FIG. 8 shows an examplepaging message indicating that a paging trigger is for MTC devicetriggering. An MTC WTRU in RRC_IDLE or RRC_CONNECTED mode may read themtc-Triggerindication 801 to know if this paging message was initiatedfor MTC device triggering. The WTRUs that are monitoring the MTCtriggers may perform further actions on receiving this indication whichmay include reading additional or new system information fields to getfurther information associated with the device trigger, and may initiatethe trigger response according to the device trigger received.

FIG. 9 shows an example RRC paging/MTC device trigger message having thenew message format. If an RRC paging/MTC device trigger message 901 isdedicated to MTC device triggering/reaching, one or more of thefollowing may be specified. The L1/2 signaling for the MTC device pagingmay use the same paging radio network temporary identity (P-RNTI) or anew MTC-P-RNTI, but in a different physical downlink control channel(PDCCH) search space for the MTC devices or in an extended PDCCH(E-PDCCH) search space for the MTC devices. The new search space for theMTC trigger/reach signal, for example, MTC-P-RNTI, whether it is in aPDCCH or an E-PDCCH and the associated paging/trigger message data maybe confined to the center portion of the carrier or channel frequencyrange to suit the narrow bandwidth MTC devices/WTRUs. The RRC paging/MTCdevice trigger message 901 may take a new message format so that thepaging/trigger message may also serve as a downlink MTC device signal towake the MTC device/WTRU 905 up and to directly command the MTCdevice/WTRU 905 for certain actions desired by the MTC service operatoror application.

The cell broadcast service (CBS) mechanism in LTE may be equated to thewarning message broadcast in the form of the E-UTRAN system informationbroadcast mechanisms. The cell-broadcast method may be applied to bothnon-attached (offline) and attached (online) devices. For MTC devicetriggering, one or more of the following new actions may be employed.

A new system information block (SIB) or SIB set may be devised for theMTC device triggering purpose. A separate system information (SI)message may be used for this CBS for MTC device triggering. In additionto an MTC triggering primary notification, the new MTC device triggersystem information may alternatively include secondary notification dataincluding MTC operator specific group identifier, MTC operator specificindividual identifier, and secure information from the MTC server. TheSI may be broadcast in the cell, and the device trigger content maychange at each transmit occasion, not preserving the MP boundary rule.Therefore, there would be no need to indicate the content change in thepaging messages. WTRUs may not wait for the modification period (MP)boundary to read it. The WTRUs may read it anytime they need to, forexample, according to their own power saving schedule or theMTC-trigger-SIB scheduling or both.

If the CBS MTC device trigger message is dedicated to MTC devicetrigger/reach, one or more of the following may be specified. In orderto save system resources and create no impact to the legacy WTRUs, analternative method to schedule the MTC device trigger/reaching SI,independently of the regular SI scheduling, may be to use a differentMTC-SI-RNTI for downlink control information (DCI). For narrow bandwidthMTC devices, the SI-RNTI or the MTC-SI-RNTI may be transmitted in PDCCHor E-PDCCH in a search space that is in the center portion of thecarrier or channel frequency range.

The SI occasion frame number may take the form of [SFN modMTC-periodicity=MTC-offset], where both MTC-periodicity and MTC-offsetmay be predetermined or network configured. For the subframe number tobegin the MTC device trigger transmission, it may be from any subframenumber excluding #0 and #5 since the WTRU may need to acquire the MIBand SIB-1 at the time. The SI transmission window length may be 1 to w,where w may be predetermined or configured by the network. If thetransmission window size is one subframe, the SI may be transmitted withone or more HARQ RV at the same time or the SI may be transmitted withno hybrid automatic repeat request (HARQ) redundancy expected.

The MTC device trigger/reaching SIB may contain one or more of thefollowing information: one or more MTC-Group-ID, which may contain theMTC-IDs within the group; the trigger category or purpose or command ortype of the MTC trigger for each MTC-ID; the trigger response type; anindication on whether an access delay may be applied and the parameterto calculate the access spread.

A new RRC message for MTC device trigger may be transmitted in the MBSFNsubframes. The MTC message may be changed anytime.

A new RRC message may be designed to carry the MTC device triggerinformation to MTC devices. The scheduling of the new message may be oneof the following. The new message may be transmitted in the sameoccasion as the existing MBSFN RRC messages. The new message may betransmitted last if it collided in transmission with the existing RRCMBMS messages. The MTC device/WTRU may need to decode this messageaccordingly, skipping the contents of the old MBMS messages.

The new RRC MTC message over an MBMS control channel (MCCH) may bescheduled more frequently in specific MBSFN subframes such as the firstavailable MBSFM subframe in an LTE frame with [SFN mod(mcch-RepetitionPeriod/n)=mtc-mcch-Offset], where n is a number of [2,4, 8, 16] and the mtc-mcch-Offset is a [1,2,3, . . . ,mcch-RepetitionPeriod/n]. The new MTC device ID or theMTC-Device-Group-ID may be employed as the MBMS-service-ID, for example,the temporary mobile group identity (TMGI).

MTC devices/WTRUs may use the assigned MTC device or device groupidentity, MTC service or service group identity, or MTC application orapplication group identity, and the like as the MBMS-service-identity,(i.e., TMGI), and the MBMS session identity to look for MTC devicetrigger information in MBMS multicast data stream. MTC Devices/WTRUs mayreceive the existing MBSFN area configuration message to determine thepresence/absence of a specific MBMS service IDs that mapped to the abovementioned MTC Device-ID or other MTC service/application relatedidentities.

MTC devices/WTRUs may decode the MBSFN area configuration message anduse the mapped MBMS service-Id (i.e., TMGI) to receive the specific MTCDevice Trigger transmission information in an MBMS transmission, forexample, the logical channel identity of a particular MBMSpoint-to-multipoint traffic channel (MTCH). MTC devices/WTRUs mayreceive the MSI (i.e., medium access control element (MAC CE)) todetermine the MBSFN subframe(s) that contains the MTC device triggerinformation from the MTCH logical channel identity. The MBMS-Service-IDmay be placed either in the beginning or the end of the MBMS trafficchannel (MTCH) transmission. For example, the MBMS trigger informationmay be placed as the first MTCH in the first MBSFN subframe or the last.

The MBMS service-ID of the MTC device/WTRU may be a certain MTCidentity, such as a device ID, service-ID or application-ID, assigned inthe universal subscriber identity module (USIM) or be constructed by theMTC device with some parameter in the USIM and some data from the systeminformation.

If the WTRU is already connected, the MTC device trigger may betransmitted via a new MAC CE. The new device trigger MAC CE may containthe MTC application ID and other application specific content. The newCE may be transmitted to the WTRU independently or together with otherdownlink data packets. The eNB may decide whether a device trigger MACCE may be transmitted, depending on the device trigger indicationreceived on S1 signaling from the MME. Upon receiving this MTC devicetrigger MAC CE, the WTRU MAC layer may directly submit the content ofthe CE to the intended MTC application.

If the MTC device/WTRU receives the MTC device trigger in a connectedstate, the device/WTRU may respond by establishing a specific U-planeconnection even if the request does not specifically ask for it but thedevice/WTRU has certain amount of application data to transmit. Forexample, the specific U-plane connection may be a packet data network(PDN) connection/packet data protocol (PDP) context to a specific APNspecified in the trigger message or by the need of the application datatransfer.

Alternatively, the device/WTRU may respond with the existing C-planeconnection if there is no specific data or small data to be transferredto the network.

Alternatively, the device may be provided with at least one method ofresponse, such as in a specific order. For example, the device mayperform a set of procedures in the given, or any other, order: {controlplane (CP)-SMS, CP-other, UP-PDN, UP-other, UP-local IP access (LIPA),UP-selected IP traffic offload at local network (SIPTO@LN)}. Thus, thedevice may attempt to respond according to the list provided and itscapabilities as well. For example, the device may try a particularmethod or eliminate certain methods if the device does not support theseschemes. Alternatively, the device may use the CP even if the responsetype is set to UP, given the UP may not be set up, for example, due toAPN congestion or any other problem that might prohibit the setup of therequired/request/desired response type. The device may attempt anothermethod of response, even if not requested/specified in the trigger, whenthe specified method fails or cannot be met due to any problem, forexample, congestion, device settings, radio conditions, andcapabilities.

In addition, the device may respond according to any time limitation itmay receive in the trigger. The possible time limitations may be asdefined above. Moreover, if the response type indicates a response via aspecific PDN/APN that may be a LGW, the device may attempt to establisha PDN connection to the specific PDN/APN, for example, a LIPA orSIPTO@LN connection may be established by the device.

If the MTC device/WTRU does not have an RRC connection/MM connectionwith the network then, depending on the MTC triggering type thedevice/WTRU has received, the WTRU may respond to the trigger message atvarious time occasions as follows.

If the trigger message the WTRU received is deemed “non-definitive timeconstraint” for response, the WTRU may transmit the response when theWTRU gets connected to the network again for some other non-MTC relateduplink transmission occasions, for example, the next TAU or attach ordetach.

If the trigger message comes with a response time duration, eithernetwork worked configured time or predefined time, the WTRU may transmitthe response with the non-MTC uplink transmission before the timeduration is over, or start a RRC connection when the response timeduration is about to expire and transmit the trigger response message.For example a predetermined time frame may be that a water company wantsthe water meter to report the water usage within a given time frame orpredefined time frame.

If the trigger message requires the WTRU to respond immediately, theWTRU may start to transmit the trigger response as requested.

If the triggering is a group type triggering, if there is a spread timeincluded in the message, the WTRU may draw a random number within thetime frame given by the network and transmit back the response message.If there is no timer given in the triggering message, the WTRU maytransmit back the trigger response message immediately, or the WTRU mayimpose a delay to transmit back the triggering response to avoidoverloading the network and/or the RAN.

Depending on type of triggering message the WTRU receives, the responsemessage may be transmitted in one or more of the following ways. The MTCdevice may transmit back the trigger response message via SMS. The MTCdevice may establish a PDP context or a PDN connection and communicateto the MTC server via the U-plane. The MTC trigger response message maybe an MM level NAS message. If the network expects an ACK or a shortresponse from the MTC device, the MTC device may transmit a triggeringresponse with one of more of the following.

The trigger response may be a simple ACK to acknowledge that the MTCdevice has received the trigger message, a combined ACK indicating thatthe MTC device has received the trigger and the requested action hasbeen performed successfully, or an action-NACK indicating that thetrigger message has been received by the MTC device but the requestedaction is rejected or failed.

The trigger response may be encapsulated or included in an existing RRCmessage. In case the access stratum (AS) level authentication has notbeen completed, the eNodeB may alternatively delay forwarding thetrigger response message until the authentication procedure has beencompleted. The trigger response may be included in the RRC connectionrequest message, or the trigger response may be attached to the RRCconnection complete message.

If the RRC message is used to carry the trigger response, to limit theresources used for MTC triggering and response procedure, someenhancement to the authentication procedure may be made for MTC. Thenetwork may enclose a standard or MTC specific authentication requestmessage or IEs in the trigger request message. The authentication methodmay either be standard authentication key agreement (AKA) or modifiedMTC-specific authentication method. After the MTC device authenticatesthe network, the MTC device may enclose an authentication response IE inthe trigger response message. When the network has authenticated the MTCdevice, the network may forward the triggering response message to theMTC-IWF and thereafter the MTC server.

The trigger response message may be encapsulated, attached, or includedin an NAS message, including but not limited to the following; attachrequest message, TAU, service request or/extended service request,uplink NAS transport, and the like.

In order to save WTRU battery life and reduce Uu interface load, if adevice trigger (DT) is not real time or emergency, the WTRU/MTCapplication may delay the response. For example, a water meter companymay trigger a water meter application to upgrade its software. Thetrigger may be transmitted to a group of MTC devices. If the requirementis that all MTC applications have to upgrade to a new version ofsoftware within a day, then it is not necessary for all of the MTCapplications to start upgrading their software immediately after beingtriggered. In some cases, the triggering response may be delayed.

In the DT trigger message, the network/SCS may specify a delay responsetime that it expects of the MTC application. After the WTRU receives thetriggering message, the WTRU may delay to dispatch the trigger to theMTC application until either the delay response time expires or the WTRUgoes back to connected mode by another procedure, for example, TAU or MOcall. Alternatively to reduce Uu traffic, if the trigger the WTRUreceived is a group trigger, the WTRU may randomly choose a responsetime within the delay response time. Alternatively, the WTRU maydispatch the trigger to the MTC application immediately, but when theMTC application responds, the WTRU delays the response message untileither the delay response time expires or the WTRU returns to aconnected mode by another procedure, for example, TAU or MO call.

FIG. 10 shows an example of a delay response procedure. FIG. 10 includesan MTC application 1005, an MTC device/WTRU 1010, a RAN+MME 1015, anMTC-IWF 1020 and an SCS 1025. A device trigger 1030 is transmitted fromSCS 1025 to MTC-IWF 1020. The device trigger 1035 is forwarded to theRAN+MME 1015. When the RAN+MME 1015 triggers the MTC application 1005,it may use paging, a cell broadcast, a NAS message, or SMS as atriggering message 1040 transmitted to the MTC device/WTRU 1010. In thetriggering message 1040, the network may specify the MTC device ID orMTC group ID to specify which WTRU, or a group of WTRUs, may receivethis trigger. The triggering message may include a maximum delayedresponse time value, which indicates the latest time that the SCS 1025expects to receive a response from the MTC application 1005. Thetriggering message 1040 may include an MTC application ID or an MTCapplication group ID to identify at least one MTC application 1005 thathas been triggered. The purpose of the triggering, for example, asoftware upgrade, may be a value that is transparent to the MTCdevice/WTRU 1010.

When the MTC device/WTRU 1010 receives a triggering message 1040including a device trigger (DT), the MTC device/WTRU 1010 may store 1045the DT and start a timer. The timer may be set to a maximum delayedresponse time value or a value based on the maximum delayed responsetime value, for example, a maximum delayed response time value-n DRXcycle. Alternatively, the timer may be set to a random number selectedfrom a value between 0 and the maximum delayed response time value. Whenthe WTRU transitions to an RRC connected mode 1050, for example, afterthe timer expires, the WTRU may dispatch 1055 the DT to the MTCapplication 1005. The MTC application 1005 may establish 1060 an IPconnection with the MTC server 1025 if a response is requested.

FIG. 11 shows that the MTC device/WTRU may delay the response messagetransmitted by an MTC application. FIG. 11 includes an MTC application1105, an MTC device/WTRU 1110, a RAN+MME 1115, an MTC-IWF 1120 and anSCS 1125. A device trigger 1130 is transmitted from SCS 1125 to MTC-IWF1120. The device trigger 1135 is forwarded to the RAN+MME 1115. When theMTC device/WTRU 1110 receives the triggering message 1140, it maydispatch 1145 it to the MTC application 1105. The MTC application 1105may choose to transmit a trigger response message 1150, in which the MTCapplication 1105 may specify the maximum delay that the trigger responsemessage may tolerate. The MTC device/WTRU 1110 may store 1155 thetrigger response message if it is in idle mode. The MTC device/WTRU 1110may start a timer based on the maximum delay value, for example, amaximum delay−n DRX cycle. When the timer expires, the MTC device/WTRU1110 may trigger the establishment of an RRC connection 1160, establishan IP connection 1165 between the MTC application 1105 and the SCS 1125,and forward the triggering response message to the SCS 1125.Alternatively, when the MTC device/WTRU 1110 transitions to the RRCconnected mode, for example, after the timer expires, the MTCdevice/WTRU 1110 may then establish the IP connection between the MTCapplication 1105 and the SCS 1125, and forward the triggering responsemessage to the SCS 1125.

The MTC device trigger response may be an NAS message at the MM level.The response message may be transmitted as an independent NAS message inresponse to the trigger if the device/WTRU is in a connected state. TheMTC device trigger response may also be a first MM level message afterthe RRC connection has been established, for example, to transmit theservice request, such as an extended service request, and the triggerresponse message together in the RRC connection setup complete messageas the “DedicatedInfoNAS” component, if the device is in “online” statebut no RRC connection. If the device/WTRU is in the “offline” state, theresponse message, as the first NAS message, may serve for both theattach and the trigger response.

For the dual purpose message, for example, the extended servicerequest+trigger response or the attach+trigger response, the necessaryelements of the service-request or the attach-request may need to be puttogether with the MTC device trigger response elements to serve the dualpurpose.

FIG. 12 shows an example of the message format of dual purpose MTCdevice service or attach+trigger response message. FIG. 12 includes IEI1205, an information element 1210, a type/reference of the informationelement 1215, presence of the information element 1220, format of theinformation element 1225, and length of the information element 1230.The information elements contained in the dual purpose MTC deviceservice or attach+trigger response message may be protocol discriminator1210(a), MTC service message identity 1210(b), MTC response type1210(c), MTC trigger response ID 1210(d), MTC response details 1210(e),MTC cause 1210(f), and authentication response parameter 1210(g).

To avoid excessive authentication/security overhead, authenticationresponse parameters may be added in the trigger response message, whenthe message is transmitted as the first NAS message after RRC connectionestablishments. To help the network to distinguish whether user planeEPS bearers may need to be established or not upon receiving the MTCtrigger response included in the first NAS message extended-servicerequest, an indicator of flag may be added to the combined message, suchas an EPS bearer type. The indicator or flag may indicate whether theuser plane EPS bearers, in addition to the C-plane bearer, may need tobe established or not for this trigger response. The network may be ableto derive from one or the MTC response parameters, for example the MTCtrigger response type, the MTC trigger response ID or the MTC cause.

FIG. 13 shows an example extended-service request message content. FIG.13 includes JET 1305, an information element 1310, a type/reference ofthe information element 1315, presence of the information element 1320,format of the information element 1325, and length of the informationelement 1330. The information elements contained in the extended-servicerequest message may be protocol discriminator 1310(a), security headertype 1310(b), extended service request message ID 1310(c), service type1310(d), NAS key set ID 1310(e), M-TMSI 1310(f), CSFB response 1310(g),EPS bearer context status 1310(h), device properties 1310 (i), deviceproperties 1310(j), EPS bearer type 1310(k), MTC response type, 1310(l),MTC trigger response ID 1310(m), MTC response details 1310(n), MTC cause1310(o), and authentication response parameter 1310(p).

The information elements for the MTC device trigger response may includeone or more of the following: the MTC trigger response type 1310(l),which may include a simple ACK, a combined ACK, and a NACK, and thelike, the MTC trigger response ID 1310(m) assigned in the MTC triggerrequest for associate the response to the request, MTC response details1310(n) from the MTC application, MTC-cause 1310(o) for theMTC-response-type value NACK.

FIG. 14 shows an example bit map that defines a cause value. The bitvalue 000001 1405 may represent that the Requested Application does notexist. The bit value 000010 1410 may represent that the RequestedApplication does not respond. The bit value 000100 1415 may representlow battery. The bit value 001000 1420 may represent not enough memory.The bit value 010000 1425 may represent other.

If the WTRU has several MTC applications, the following situations mayexist and need to be handled: the WTRU is Idle and no MTC application isactive. When a WTRU is connected and at least one MTC device is active,a non-active MTC application may be triggered. When the WTRU hasmultiple MTC applications and it is in a connected mode with any non-MTCapplication running, or one of the MTC applications is active, then theactive application path may be used to trigger the MTC device. The SCSmay include/encapsulate the MTC device trigger message in theapplication data, for example, through the user-plane triggering pathand method. When the active MTC application or an MTC handling entityreceives that trigger message it may perform the device triggerprocedure and transmit the appropriate reply. This trigger message mayinclude some of the information elements described above.

A WTRU/user may need to register with the network and with operators toreceive services that require registration. This registration isdescribed as network attachment. The WTRU registers its presence to thenetwork in the registration area of the chosen cell if necessary bymeans of a location registration (LR), LTE attach, GPRS attach, IMSIattach procedure or combined attach procedures. For example, in the caseof LTE, in the state EMM-deregistered, no EMM context has beenestablished and the WTRU location is unknown to an MME and therefore itis unreachable by an MME. In order to establish an EMM context, the WTRUmay start the attach or combined attach procedure.

An offline MTC device is a device/WTRU that is unattached to thenetwork, for example, the device is not registered with the network. Itmay also have been registered with the network but then may bede-registered with the network, for example, with some timer andmonitoring function remaining, in order to save power.

FIG. 15 shows the primary EMM states in an MTC device/WTRU. The MTCdevice/WTRU may be in any one of 7 states: EMM-Registered 1505,EMM-Deregistered 1510, EMM-Null 1515, EMM-Deregistered-Initiated 1520,EMM-Tracking-Area-Updating-Initiated 1525, EMM-Service-Request-Initiated1530, and EMM-Registered-Initiated 1535.

For example, as shown in FIG. 15, an offline MTC device/WTRU may be inan EMM-deregistered state 1510 or in an EMM-null state 1515. When theMTC device/WTRU transitions from a EMM-registered state 1505 to theEMM-deregistered state 1510, the MTC device/WTRU may communicate to thenetwork with information to help the network reach the MTC device/WTRUor trigger the MTC device/WTRU to transition it from an offline state toan online state and/or to perform certain commanded actions by MTCdevice server/application. For example, an online state may be when theWTRU is again attached to the network at trigger response.

In another embodiment, when the device is transitioning from a statewhere the device is not registered 1510 to the network to a state wherethe device is registered 1505 to the network, the MTC device maycommunicate to the network information to help the network reach thedevice or trigger the device to transition from an offline state to anonline state after the device returns to an offline state or status. Forexample, an online state may be when the WTRU is registered to thenetwork.

In another embodiment, another terminal device or network element mayprovide the offline triggering support parameters to the network. Forexample, in a local network, the LGW or the H(e)NB or any other MTCdevice aggregator node may store locally these parameters and providethem to the rest of the network either upon request or autonomouslybased on configurable triggers. For example, a network element, such asa home network element, may store locally these parameters and providethem to another network, such as a visited network or another equivalentPLMN or another shared network, upon request or autonomously based onconfigurable triggers.

A certain portion of MTC devices may have an attribute that they may beattached/registered to the network and perform data transfer for a shortperiod of time and go back to un-attached/de-registered state (i.e., theoffline MTC device) via “de-registration” or other procedures for alonger period of time for power-saving and other purpose while remainingalert to receive network MTC device trigger/reach signals. MTC deviceswith the above offline attribute may notify the network with theattribute and the information enabling the network to trigger/reachthem. The network may know and be able to handle the “offline” devicesin terms of device triggering/reaching. The MTC devices/WTRUs maytransmit the information using one or more NAS messages or a combinationof RRC message together with a RAN interface message, for example, acombination of RRC message+S1-AP or radio access network applicationpart (RANAP) message. The information provided to the network mayinclude one or more of the following.

The MTC device/WTRU may provide its “offline” attribute to the networkvia NAS messages such as an ATTACH message or the NAS area updatemessage or a detach message. For example, the NAS area update messagemay be a tracking area update (TAU). The MTC device/WTRU may provide thedevice roaming area information to the network in the NAS procedures (ormessages) at EMM (or MM) level such as the detach procedure, the attachprocedure, or the TAU/LAU/RAU procedures. For example the detachprocedures may be a detach request message, the attach procedures may bean attach request message, and the TAU/LAU/RAU procedures may be atracking area update request message.

The information, for example, parameters, provided by the MTC device tothe network may be a list of tracking areas, location areas, routingareas, or a list of cells identified, for example, by their globalidentifier. Such list may be a subset from a super list provided by thenetwork to the WTRU during a prior information exchange between the MTCdevice and the network. Such list may be based on prior areas visited bythe MTC device or registered by the MTC device. The roaming areainformation may also be one single area or a fixed location attribute,such as no roam/mobility.

The MTC devices may provide their device trigger/reaching monitoringoccasion information to the network. For MTC, the network may define orprovide a specific set of monitoring schedules, timer values, orDRX/sleep cycle lengths and the device may indicate which one or more ofthe schedules it follows when it goes offline. The device may choose totransmit its monitoring schedule explicitly in the message before itgoes offline. If there is more than one MTC monitoring mechanism, suchas paging vs. CBS vs. multicast, the MTC device may also need toindicate which one or more than one is supported/used.

The validity of the information provided by the WTRU to the network forthe purpose of offline triggering may be controlled by a timer. Thetimer value may be “infinity until waived by the device or byadministration.” Upon expiry of such a timer, the network may purge allsuch information from its database and consider the offline MTC devicenot reachable. Alternatively, the MTC device may be configured toconnect to the network and refresh the network with its reachabilityinformation before or upon expiry of the timer.

The MME or SGSN or any equivalent CN node with NAS protocol capabilitymay receive and process the messages containing the above MTC deviceoffline and trigger/reaching information. The function that makes thedetermination of whether or not a device is “offline (and reachable)”may be located in the MME (or SGSN or GGSN/S-GW/PGW), in the HSS (orHLR), in the MTC-IWF, in the SCS, or in the MTC application inside oroutside the 3GPP network.

The device reachability information may be propagated from the MME tothe network node where the function of offline status determination islocated, such as in the MTC-IWF. For example, the device reachabilityinformation may be parameters of location, triggering mechanism, andscheduling. Alternatively, the MTC-IWF, upon receiving a request fromthe MTC server, may query the HSS (HLR) in a scheme where the HSS isresponsible for keeping track of the device status together with theinformation on how to reach the device when offline. The MTC-IWF maysubsequently ask the MME to trigger the device.

Alternatively, the SCS may contact the SMS-SC, which in turn queries theHSS for the device status. Alternatively, once a determination is madethat a device is offline, such status may be conveyed to the MTC-IWF orSCS of the MTC application. Alternatively, the device may be offline butnot reachable, for example, the reachability information provided by theMTC device to the network has expired. When the device is offline andpreviously reachable becomes unreachable, such information may bepropagated back to the SCS of the MTC-IWF.

Various procedures may be implemented to identify WTRUs of a certainpriority, or identify applications for WTRUs that have differentpriorities. This may be applicable when a WTRU has an emergency bearerservice or is requesting an emergency bearer service. The terminology“priority WTRU” may refer to any combination of the following: a highpriority user/WTRU, a WTRU that belongs to a specific access class, forexample, 11-15, or a WTRU having at least one priority application.Moreover, the terminology “priority application” may refer to anapplication that is known to carry priority content, a PDN connectionthat is associated with a known APN that provides high prioritycontent/packet/application, an application, PDN connection, or adedicated bearer (PDP context) that has, or requests, a known quality ofservice (QoS).

A WTRU profile may contain information indicating whether a particularWTRU is a priority WTRU or runs a priority application. The WTRU may beprovided with information about being a priority WTRU via open mobilealliance (OMA) device management (DM) or other NAS messages. The WTRUmay also have such information preconfigured. The WTRU may alwaysinclude such information in all NAS messages, including mobility andsession management messages, or RRC messages. The WTRU may also alwaysindicate if the access made from idle mode is performed with accessclass 11-15 or any other access class. Additionally, an eNB may indicateto the MME, in all S1AP messages, the set of classes that the eNB isallowing for access.

The network may include this information in all NAS messages or RRCmessages. When the RRC in the WTRU receives such an indication, the RRCmay inform the NAS about it or may pass the information to the NAS.

BO timers may be provided on a per application basis. An application IDmay be introduced in NAS messages in order to identify the referencedapplication. A WTRU that receives a BO timer for an application may nottransmit any NAS messages due to requests from the application to whicha BO was assigned. The WTRU may stop such a timer if the networkinitiates session management requests for bearers/PDN connections usedby this application. An application may be associated with a PDNconnection mapping or a bearer mapping. The mappings may be performedvia an identification that points out such an association. Thisidentification may be part of all NAS messages. For example, all NASmessages may include an application ID and an association ID that mapsthe application to a specific bearer. Alternatively, the application IDmay be used as the association parameter that maps the application to aparticular bearer. BO timers may also be provided on a per bearer basis.

The CN nodes may exchange this indication. Further more this indicationmay be on a per application basis. Also, the CN nodes may exchangeinformation about whether the WTRU in question is allowed to be apriority WTRU or have priority applications.

When a WTRU receives an indication that it is a priority WTRU or when italready has such information, for example, due to configuration, theWTRU may transmit mobility and session management messages that are notrelated to emergency calls, even if the WTRU has an emergency call. TheWTRU may transmit a NAS message to update the network with the newpriority level. The WTRU may be allowed to transmit mobility and/orsession management messages that are due to requests from applicationsthat are high priority only. The WTRU may further include indicationsthat a particular request is for a high priority application. The WTRUmay also transmit requests due to low priority applications and mayindicate that the request is due to a low priority application. The WTRUmay request the modification of certain bearers such that they aretreated as bearers pertaining to a high priority WTRU/application ornon-high priority, depending on the current WTRU/application priority.For example, if the current priority for a WTRU/application is high,then the WTRU may indicate as such in its request for modifying thebearers. If the priority for the WTRU is low, then the WTRU may requestmodifications indicating a non-high priority WTRU.

The above may be provided via RRC messages to the eNB/RNC. In this case,the eNB/RNC may forward such indication/information to the core networknodes via new/existing messages with new/existing information elements(IEs).

The following are network (eNB/RNC/MME/SGSN or MSC/VLR) actions when thenetwork receives an indication about the WTRU's priority or priority ofapplications. This may be received in the form of NAS messages orS1AP/RANAP messages (or any similar messages).

The network may use this indication/information to accept requestsregardless if they are not for emergency calls. For example, if the MMEreceives a request,(NAS mobility or session management message),with anindication that the WTRU/application is a low priority, then the MME mayprovide a BO timer to the WTRU. The BO timer may be per APN or perapplication. As another example, if the MME receives a request from aWTRU that indicates high priority, the MME may accept the request andprocess it.

The network may modify the bearers for the WTRU. For example, the MMEmay indicate to the S-GW to modify the bearers of the WTRU, for example,using the bearer modification request. The S-GW may also in turn requestthe PDN GW to modify the bearers for the WTRU. The modification may besuch that the QoS/treatment/priority of the connection is improved ordegraded, depending on the indication received. For example, if the MMEreceives an indication about the WTRU being a high priority WTRU, forexample, an indication downloaded from an HSS or received from the WTRU,then the MME may indicate to the S-GW that the WTRU's bearers may betreated as those pertaining to a priority WTRU. This may be achieved viaa new or existing IE in the messages exchanged between the MME and theS-GW.

The same methodology may also apply for the S-GW indication towards thePDN GW. A reverse indication may also apply, for example, the PDN GW mayprovide the S-GW/MME with an indication about a change in the WTRU'spriority, or application priority. This may be performed by transmittinga message towards the S-GW, which in turn may transmit a message withsuch an indication towards the MME. The MME may then take the actionsdefined above. Alternatively, the MME may use this indication to modifythe bearers for the WTRU and may therefore transmit NAS messages to theWTRU to indicate the change of priority of the WTRU. The MME may alsoinform the eNB that the WTRU priority has changed, for example, usingSlAP messages similar to a WTRU context modification request. The eNBmay, upon receipt of an indication of a change in WTRU priority, executean RRC reconfiguration procedure to implement the change in WTRUpriority.

The network, (i.e., MME/SGSN/GGSN/PDN GW, or MSC/VLR), may decide toprovide a BO timer to the WTRU, for example, if the indication is from alow priority WTRU or from a WTRU that does not indicate high priority.Furthermore, the network may decide to stop any existing BO timers thatare running for a WTRU/application that indicates high priority.

The above procedures may be applicable to both LTE and GERAN/UTRAN, andto both PS and CS domains/core networks, and may be used in anycombination.

Although features and elements are described above in particularcombinations, one of ordinary skill in the art will appreciate that eachfeature or element may be used alone or in combination with any of theother features and elements. In addition, the embodiments describedherein may be implemented in a computer program, software, or firmwareincorporated in a computer-readable medium for execution by a computeror processor. Examples of computer-readable media include electronicsignals, (transmitted over wired or wireless connections), andcomputer-readable storage media. Examples of computer-readable storagemedia include, but are not limited to, a read only memory (ROM), arandom access memory (RAM), a register, a cache memory, a semiconductormemory device, a magnetic media, (e.g., an internal hard disc or aremovable disc), a magneto-optical media, and an optical media such as acompact disc (CD) or a digital versatile disc (DVD). A processor inassociation with software may be used to implement a radio frequencytransceiver for use in a WTRU, UE, terminal, base station, Node-B, eNB,HNB, HeNB, AP, RNC, wireless router or any host computer.

What is claimed is:
 1. A method for triggering at least one machine typecommunications (MTC) application using at least one wirelesstransmit/receive unit (WTRU), the method comprising: receiving atriggering message including a device trigger (DT) and a maximum delayedresponse time value from a core network entity (CN); storing the DT inthe WTRU; initiating a timer in the WTRU set to the maximum delayedresponse time value; and on a condition that the timer expires, the WTRUtransitioning to a radio resource control (RRC) connected mode anddispatching the DT to the MTC application.
 2. The method as in claim 1,wherein the CN entity is a mobility management entity (MME).
 3. Themethod as in claim 1, wherein the CN entity is a serving general packetradio service (GPRS) support node (SGSN).
 4. The method as in claim 1,wherein the CN entity is a mobile switching center (MSC).
 5. The methodas in claim 1, wherein the triggering message is received in a cellbroadcast.
 6. The method as in claim 1, wherein the triggering messageis received in a non-access stratum (NAS) message.
 7. A method fortriggering at least one machine type communications (MTC) applicationusing at least one wireless transmit/receive unit (WTRU), the methodcomprising: receiving a triggering message including a device trigger(DT) and a maximum delay value from a core network (CN) entity; the WTRUdispatching the DT to the MTC application; receiving, at the WTRU, atrigger response message from the MTC application; storing the triggerresponse message in the WTRU; initiating a timer in the WTRU set to themaximum delay value; and on a condition that the timer expires, the WTRUtransitioning to a radio resource control (RRC) connected mode andforwarding the trigger response message to an MTC server.
 8. The methodas in claim 7, wherein the CN entity is a mobility management entity(MME).
 9. The method as in claim 7, wherein the CN entity is a servinggeneral packet radio service (GPRS) support node (SGSN).
 10. The methodas in claim 7, wherein the CN entity is a mobile switching center (MSC).11. The method as in claim 7, wherein the triggering message is receivedin a cell broadcast.
 12. The method as in clam 7, wherein the triggeringmessage is received in a non-access stratum (NAS) message.
 13. A methodfor triggering at least one machine type communications (MTC)application using a control) in a core network (CN) entity, the methodcomprising: receiving an MTC device trigger request from anMTC-interworking function (IWF); transmitting an acknowledgment that theMTC device trigger request is being processed; determining if the MTCdevice trigger request includes a preference of point-to-point delivery;and transmitting the MTC device triggering request to a wirelesstransmit/receive unit (WTRU) using point-to-point delivery.
 14. Themethod as in claim 13, wherein the CN is a mobility management entity(MME).
 15. The method as in claim 13, wherein the CN entity is a servinggeneral packet radio service (GPRS) support node (SGSN).
 16. The methodas in claim 13, wherein the CN entity is a mobile switching center(MSC).
 17. The method as in claim 13, wherein the MTC device triggeringrequest message is received in a cell broadcast.
 18. The method as inclaim 13, wherein the MTC device triggering request message is receiveda non-access stratum (NAS) message.
 19. A wireless transmit/receive unit(WTRU) for triggering at least one machine type communications (MTC)application, the WTRU comprising: a receiver configured to receive atriggering message including a device trigger (DT) and a maximum delayedresponse time value from a core network entity (CN); a processorconfigured to store the DT; the processor further configured to initiatea timer set to the maximum delayed response time value; and on acondition that the timer expires, the processor is further configured totransition to a radio resource control (RRC) connected mode and atransmitter configured to dispatch the DT to the MTC application.